home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 2041 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.4 KB  |  94 lines
  1. Newsgroups: comp.lang.c
  2. Path: bristol.com!handel!dan
  3. From: dan@bristol.com (J. Daniel Smith)
  4. Subject: Re: Q: realloc->free?
  5. Sender: usenet@bristol.com (USENET News System)
  6. Organization: Bristol Technology Inc.
  7. References: <4df2ud$706@oxy.rust.net> <4dgic7$qin@unix.sri.com> <dan.821890778@handel> <821904243snz@genesis.demon.co.uk>
  8. Message-ID: <dan.821977599@handel>
  9. Date: Thu, 18 Jan 1996 15:06:39 GMT
  10.  
  11. In <821904243snz@genesis.demon.co.uk> Lawrence Kirby <fred@genesis.demon.co.uk> writes:
  12. >[...]
  13. >>adding code to deal for the extremely rare case can add
  14. >>significantly to the complexity of the code.
  15.  
  16. >Adding error checking for heap allocation makes minimal difference to
  17. >program complexity. OTOH dealing with rare cases properly makes the task
  18. >of debugging much easier.
  19.  
  20. Here's an example of what I had in mind
  21.    void f(const char *string)
  22.    {
  23.       static char *buf = NULL;
  24.  
  25.       buf = realloc(buf, strlen(string) + 1);
  26.       /* ... do whatever with buf ... */
  27.    }
  28. Dealing with the realloc() failure makes this
  29.    void f(const char *string)
  30.    {
  31.       static char *buf = NULL;
  32.       char *tmp;
  33.  
  34.       if ((tmp = realloc(buf, strlen(string) + 1)) == NULL)
  35.     return; /* realloc() failed...now what? */
  36.       buf = tmp;
  37.       /* ... do whatever with buf ... */
  38.    }
  39. This prevents a crash, and in that respect it is definately more
  40. robust than not checking realloc()'s return value.  But does the
  41. program still run correctly?  Not likely, since whatever f() was
  42. supposed to do isn't being done.
  43.  
  44. One could make all kinds of arguments about return values, error codes,
  45. poor software design, whatever.  And I'll agree that things would be
  46. better if f() were written as follows
  47.    int f(const char *string)
  48.    {
  49.       static char *buf = NULL;
  50.       char *tmp;
  51.  
  52.       if ((tmp = realloc(buf, strlen(string) + 1)) == NULL)
  53.     return 0; /* realloc() failed */
  54.       buf = tmp;
  55.       /* ... do whatever with buf ... */
  56.  
  57.       return 1;
  58.    }
  59. but in real life, this sometimes isn't an option.
  60.  
  61. >> And if realloc() does
  62. >>fail, there are probably a lot bigger things to worry about than
  63. >>leaking memory (like the GUI not being able to create a window to tell
  64. >>you something has went wrong).
  65. >
  66. >You can at the very least exit cleanly at the point of failure. If you fail
  67. >in allocation you can try to creewate an error window and exit cleanly
  68. >if that fails.
  69.  
  70. yes, this is nicer than crashing and leaving a core dump, or getting a
  71. GPF dialog box.  But a GUI application suddenly quitting for no
  72. apparent reason isn't very nice either.
  73.  
  74. >>Yes, the programmer needs to be aware of the fact that realloc() can
  75. >>fail, but in some cases ALWAYS checking the return value of realloc()
  76. >>just isn't practical given other constraints.
  77. >
  78. >I can't think of any reasonable constraints that would make it impractical.
  79.  
  80. the function above is burried 15 calls deep, many of the functions in
  81. the call chain have no provisions for checking return values.  As you
  82. say, calling exit() will at least terminate cleanly, but now I've got
  83. calls to exit() (or my own fatal_exit()) scattered all through my
  84. program which some might say is poor style.
  85.  
  86. My only real contention is with "ALWAYS" - I don't like absolutes. :-)
  87.  
  88.    Dan
  89. -- 
  90. --------------------- message is author's opinion only --------------------
  91. J. Daniel Smith <DanS@bristol.com>              http://www.bristol.com/~dan
  92. Bristol Technology Inc.                        +1 203 438 6969, 438-5013 (FAX)
  93. Ridgefield, Connecticut (USA)                       {info,jobs}@bristol.com
  94.